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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The objective of this document is to address the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and 
Izi reference points between IMS networks in order to support end-to-end service interoperability. 

The present document will address the issues related to control plane signalling (3GPP usage of SIP and SDP protocols, 
required SIP headers) as well as other interconnecting aspects like security, numbering/naming/addressing and user 
plane issues as transport protocol, media and codecs actually covered in a widespread set of 3GPP specifications. A 
profiling of the Inter-IMS Network to Network Interface (II-NNI) is also provided. 

Charging aspects will be addressed as far as SIP signalUng is concerned. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions, as specified in 3GPP TS 22.228 [9]. 

IP multimedia session: as specified in 3GPP TS 22.228 [9] an IP multimedia session is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers. IP multimedia sessions are supported by the IP 
multimedia CN Subsystem and are enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user can invoke 
concurrent IP multimedia sessions. 

non-roaming II-NNI: the II-NNI between IMS home networks. 

roaming II-NNI: the II-NNI between a visited IMS network and the IMS home network. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [34] apply: 

MSC Server enhanced for ICS 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ici Reference Point between an IBCF and another IBCF or I-CSCF belonging to a different IM CN 

subsystem network 
Izi Reference Point between a TrGW and another TrGW or media handling node belonging to a 

different IM CN subsystem network 
Mi Reference Point between a BGCF and CSCF 

Mm Reference Point between a CSCF/BGCF/IMS ALG and an IP multimedia network. 

Mw Reference Point between a CSCF and another CSCF 

Mx Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS and IBCF 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

B2BUA Back 2 Back User Agent 

BGCF Break out Gateway Control Function 

IBCF Interconnection Border Control Function 

ICS IMS Centralized Services 

I-CSCF Interrogating CSCF 

II-NNI Inter-IMS Network to Network Interface 

IM Instant Messaging 

IMS -ALG IMS Application Level Gateway 

MCID Malicious Call IDentification 

MRFC Media Resource Function Controller 

MSRP Message Session Relay Protocol 

NA(P)T-PT Network Address (Port-Multiplexing) Translation-Protocol Translation 

NNI Network to Network Interface 
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OCB Outgoing Communication Barring 

P-CSCF Proxy CSCF 

PRES Presence 

TrGW Transition Gateway 

4 Overview 

Interconnection between two different IM CN subsystems shall be guaranteed in order to support end-to-end service 
interoperability. For this purpose, Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem 
networks is adopted, according to the assumptions coming from 3GPP TS 23.002 [3] and 3GPP TS 23.228 [4]. 

Aiming to support the delivery of IMS services between two separated IM CN subsystems, protocol interconnection has 
to occur: 

at a control plane level, in order that IMS procedures can be supported. In this case the adopted reference point is 
the Ici; 

at a user plane level, where media streams are exchanged over the Izi reference point. 

The management of IP multimedia sessions is acted by using SIP. The transport mechanism for both SIP session 
signalling and media transport is IPv4 (IETF RFC 791 [2]) or IPv6 (IETF RFC 2460 [7]). The 3GPP profile of SIP 
defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [5]. Example call flows are 
provided in 3GPP TR 24.930 [6]. 

The general interconnection model is shown in Figure 4.1. 




II-NNI 




Figure 4.1 : Interconnection IVIodel for IM CN Subsystems 

The possible functional entities involved in the signalling plane interconnection (IBCF, I-CSCF, P-CSCF, BGCF and 
MSC Server enhanced for ICS) and in the user plane interconnection (TrGW) are specified in 3GPP TS 24.229 [5], in 
3GPP TS 29.292 [35] and in 3GPP TS 29.162 [8]. 

IP Version interworking is described within 3GPP TS 29.162 [8]. 



5 Reference model for interconnection between IIVI CN 

subsystems 

5.1 General 

Figure 5.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter- IMS Network to Network 
Interface (II-NNI) between two IM CN subsystem networks. 
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Figure 5.1.1 : Inter-IMS Network to Network Interface between two IM CN subsystem networks 

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface. 

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and 
forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to 
forward media streams between IM CN subsystem networks. 

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. 

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks 
belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10]. 



5.2 Functionalities performed by entities at the edge of the 
network 

5.2.1 Interconnection Border Control Function (IBCF) 

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], IBCF can act both 
as an entry point and as an exit point for a network. 

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]: they include: 

- network topology hiding; 

application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or 
between a SIP application in a private IP address space and a SIP application outside this address space); 

controlling transport plane functions; 

controlling media plane adaptations; 

screening of SIP signalling information; 

- selecting the appropriate signalling interconnect; 
generation of charging data records; 

Based on local configuration, the IBCF performs transit routing functions [5]. 
The IBCF acts as a B2BUA when it performs IMS-ALG functionahty. 

5.2.2 Transition Gateway (TrGW) 

According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled 
by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point. 
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The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds 
addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the 
two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport 
identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8]. 

Further details are described in 3GPP TS 23.228 [4]. 



6 Control plane interconnection 

6.1 Definition of Inter-IMS Network to Network Interconnection 

6.1 .1 SIP methods and headers 

6.1.1.1 General 

The functional entity closest to the border of an IMS network towards an Inter-IMS Network to Network 
Interconnection (see reference model in Clause 5) shall provide the capabilities specified for that network element in 
Annex A.2 of TS 24.229 [5] with modifications as described in the following sub-clauses. 

6.1.1.2 SIP methods 

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN 

subsystem. 

The following SIP methods are supported on the II-NNI as defined in table 6.1. 

The following table is based on Table A.5 and Table A. 163 of TS 24.229 [5] and endorsed for this document: 
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Table 6.1 : Supported SIP methods 



Item 


Method 


Ret. 


ll-NNI 


Sending 


Receiving 


1 


ACK request 


[131 


m 


m 


2 


BYE request 


[13] 


m 


m 


3 


BYE response 


[13] 


m 


m 


4 


CANCEL request 


[13] 


m 


m 


5 


CANCEL response 


[13] 


m 


m 


5A 


INFO request 


[28] 








5B 


INFO response 


[28] 








8 


INVITE request 


[13] 


m 


m 


9 


INVITE response 


[13] 


m 


m 


9A 


MESSAGE request 


[19] 








9B 


MESSAGE response 


[19] 








10 


NOTIFY request 


[20] 


Cl 


cl 


11 


NOTIFY response 


[20] 


Cl 


cl 


12 


OPTIONS request 


[13] 


m 


m 


13 


OPTIONS response 


[13] 


m 


m 


14 


PRACK request 


[18] 


m 


m 


15 


PRACK response 


[18] 


m 


m 


15A 


PUBLISH request 


[21] 


cl 


cl 


15B 


PUBLISH response 


[211 


cl 


cl 


16 


REFER request 


[22] 








17 


REFER response 


[22] 








18 


REGISTER request 


[13] 


c2 


c2 


19 


REGISTER response 


[13] 


c2 


c2 


20 


SUBSCRIBE request 


[201 


cl 


cl 


21 


SUBSCRIBE response 


[201 


cl 


cl 


22 


UPDATE request 


[23] 


m 


m 


23 


UPDATE response 


[23] 


m 


m 


c1 : In case of roaming scenario, tlie support of tlie metliod is m, else o. 
c2: In case of roaming scenario, tlie support of tlie metliod is m, else n/a. 


NOTE: In the above table, m, o and c and n/a have the meanings indicated in 
Table 6.3 



6.1.1.3 



SIP headers 



6.1.1.3.0 



General 



The IBCF shall provide the capabilities to manage and modify SIP headers according to section 5.10 and Annex A of 
TS 24.229 [5] with modifications as described in the following sub-clauses. 



6.1.1.3.1 



Trust and not trust domain 



In case there is a trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF acting as contact 
point applies the procedures described in the section 4.4 of TS 24.229 [5], before forwarding the SIP signalling to the 
next IBCF. 

In case there is not a trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF acting as 
exit point applies the procedures described in the section 5.10.2 of TS 24.229 [5] before forwarding the SIP signalling 
to the IBCF acting as entry point. The IBCF acting as an entry point applies the procedures described in the section 
5.10.3 ofTS 24.229 [5]. 

TS 24.229 [5] provide procedures for handling SIP headers based on trust domain. These procedures may be utilized on 
a per header basis to realize overall trust as well as per service level screening of headers. Trust relationships and trust 
domains may be defined by inter-operator agreements for individual services and/or individual SIP headers. 

The management of the SIP headers (if present) over II-NNI in case of a presence or not of a trust relationship between 
the two interconnected IM subsystems is wrapped up in the following table. 
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Table 6.2: Management of SIP headers over ll-NNI in presence or not of a trust relationship 



Item 


Header 


Trust domain 


Not trust domain 


1 


P-Asserted-ldentity 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


2 


P-Access-Network- 1 nfo 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


3 


Resource-Priority 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


4 


History-Info 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in Clause 4.3.3 of 
RFC 4244 [25] 


5 


P-Asserted-Service 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


As specified in 3GPP TS 24.229 
[5], clause 4.4. 
(NOTE 3) 


6 


P-Charging-Vector (see RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


7 


P-Charging-Function-Addresses (see 
RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 24.229 
[5], clause 5.10 


8 


P-Profile-Key 
(NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


9 


P-Private-Network-lndication 
(N0TE1) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


10 


P-Served-User 
(NOTE 1 , NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 24.229 
[5], clause 4.4 


NOTE 1 : For a roaming ll-NNI between a home IMS and a visited IIVIS, a trust relationship with respect to this header 

is required. 
NOTE 2: This header is only applicable on an ll-NNI between a home IMS and a visited IMS. 
NOTE 3: In addition, value-dependent operator policies may be applied. 



6.1.1.3.2 



Derivation of applicable SIP headers from TS 24.229 



For any method in Table 6.1, the SIP headers applicable on the II-NNI are detailed in the corresponding method tables 
for the UA role and proxy role sending behaviour in Annex A of 3GPP TS 24.229 [5]. Unless other information is 
specified in the normative part of the present specification, the applicability of headers at the II-NNI can be derived for 
each method from the corresponding tables in Annex A of 3GPP TS 24.229 [5] as follows: 

All headers not present in the corresponding tables in Annex A of 3GPP TS 24.229 or marked as "n/a" in both 
the "RFC status" and "profile status" columns for the UA role and proxy role sending behaviour of that tables are 
not applicable at the II-NNI. 

Note: Operators could choose to apply headers for new SIP extensions on an II-NNI based on bilateral 
agreements, but this is outside the scope of the present specification. 

All headers which are marked as "o" in at least one of the "RFC status" or the "profile status" profile columns for 
the sending behaviour in the corresponding UA role and proxy role tables in Annex A of 3GPP TS 24.229 and as 
"n/a" or "o" in the other such columns are applicable at II-NNI based on bilateral agreement between operators. 

All headers which are marked as "m" in at least one of the "RFC status" or the "profile status" columns for the 
sending behaviour in the corresponding UA role or proxy role table in Annex A of 3GPP TS 24.229 and as "n/a", 
"o", or "m" in the other such columns are applicable at the II-NNI. 

If conditions are specified, they are also applicable at the II-NNI and the above rules are applicable to the "n/a", 
"o" and "m" values within the conditions. 

Note: In the above rules, the RFC profile columns are taken into account in order to enable interworking with 
non-3GPP networks. 
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An informative summary of SIP headers to be used over the II-NNI is proposed in Annex A. 

6.1 .1 .3.3 Applicability of SIP headers on a roaming II-NNI 

The following SIP headers are only applicable on a roaming II-NNI: 
Authentication-Info 
Authorization 

- P-Associated-URI 

- P-Called-Party-ID 
P-Preferred-Service 

- P-Profile-Key 
P-Served-User 

- P-Visited-Network-ID 

- Path 

Proxy- Authentication 
Proxy- Authorization 
Service-Route 

- www-Authenticate 



6.1.1.3.4 
Void 



Applicability of SIP headers on a non-roaming II-NNI 



6.1.1.4 Notations of the codes 

In the table 6.1 the status codes m, o, c, i and n/a have the following meanings: 

Table 6.3: Key to notation codes for SIP messages 



Notation 
code 


Notation name 


Sending side 


Receiving side 


m 


mandatory 


The message shall be supported at II- 
NNI. 

Supporting sending a SIP message at 
the II-NNI means that this message shall 
be sent over the II-NNI if received from 
the serving network. It does not imply 
that network elements inside the serving 
network or user equipment connected to 
this network shall support this message. 


Supporting receiving a SIP message at 
the II-NNI means that this message shall 
be forwarded to the serving network. It 
does not imply that network elements 
inside the served network or user 
equipment connected to this network are 
supporting this message. 





optional 


The message may or may not be 
supported at II-NNI. The support of the 
method is provided based on bilateral 
agreement between the operators. 


Same as for sending side. 


n/a 


not applicable 


It is impossible to use/support the 
message. 


It is impossible to use/support the 
message. This element will be discarded 
bythelBCF. 


c 
<integer> 


conditional 


The requirement on the message ("m", 
"o" or "n/a") depends on the support of 
other optional or conditional items. 
<integer> is the identifier of the 
conditional expression. 


Same as for sending side. 



£75/ 



3GPP TS 29.1 65 version 8.1 0.0 Release 8 1 4 ETSI TS 1 29 1 65 V8.1 0.0 (201 2-01 ) 

6.1.1.5 Modes of signalling 

Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used , 
otherwise enbloc shall be used at the NNI. 

6.1.2 SDP protocol 
6.1.2.1 General 

The functional entity closest to the border of an IMS network towards an Inter-IMS Network to Network 
Interconnection (see reference model in Clause 5) shall provide the capabilities specified for that network element in 
Annex A.3ofTS 24.229 [5]. 

6.2 Control Plane Transport 
6.2.1 General 

The control plane transport of the IMS Inter-Operator Service Interconnection Interface shall comply with Clause 4.2A 
ofTS 24.229 [5]. 

Support of SCTP as specified in RFC 4168 [27] is optional for an IBCF connected by II-NNI. Nevertheless this option 
is favourable if the operators would like to improve reliability over the Ici. 



7 User plane Interconnection 

7.1 Media and Codec 

For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between 
IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because 
no common codec could be supported by the UEs, in particular for voice services. 

To enhance interoperability, the IBCF the MRFC, or other IMS network entities can interfere with the end-to-end codec 
negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure an 
attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode. 

Codecs applicable at the NNI may be a subject of interworking agreements. 

NOTE: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26. 1 14 [1 1] and ETSI TS 
181 005 [12]. 

However, to avoid that transcoding is performed several times, applicable codecs at the NNI should be restricted as 
little as possible. 

NOTE: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving 
an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can 
clarify if it is preferred that IMS network serving an SDP offerer or IMS network serving an SDP 
answerer modify an SDP offer to offer transcoding. 

If the IBCF performs media transcoding control, it shall apply the related procedures in 3GPP TS 24.229 [5]. 



7.2 User Plane Transport 



The user plane transport of the IMS Inter-Operator Service Interconnection Interface may use the protocols listed in 
Table 7.2.1. The used protocols to transport media are negotiated by means of SDP offer/answer. 
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Table 7.2.1 : Supported transport-level RFCs to be described in SIP/SDP messages 



Item 


RFC 


Title 


Support 


1 


IETF RFC 3550 [36] 


RTF: A Transport Protocol for Real-Time Applications 


Mandatory 


2 


IETF RFC 768 [37] 


User Datagram Protocol 


Mandatory 


3 


IETF RFC 3551 [38] 


RTF Profile for Audio and Video Conferences with Minimal Control 


Mandatory 


4 


IETF RFC 3556 [39] 


Session Description Protocol (SDP) Bandwidth Modifiers for RTF 
Control Protocol (RTCP) Bandwidth 


Mandatory 


5 


IETF RFC 4585 [40] 


Extended RTF Profile for Real-time Transport Control Protocol 
(RTCP) - Based Feedback (RTP/AVPF) 


Optional 
(N0TE1) 


6 


IETF RFC 793 [41] 


Transmission Control Protocol 


Optional 
(NOTE 2) 


NOTE 1 : used by MTSI, as indicated in 3GPP TS 26.1 14 [11] 
NOTE 2: used for MSRP service 





8 



Numbering, Naming and Addressing 



The following URI formats in SIP messages may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• SIP URI defined in IETF RFC 326 1 [ 1 3] ; 

• tel URI defined in IETF RFC 3966 [ 14] ; 

• IM URI defined in IETF RFC 3860 [15]; 

• PRES URI defined in IETF RFC 3859 [16]. 

Moreover, in case of MSRP sessions passing through the II-NNI, the MSRP URI may be also used at the Ici in the SDP 
exchange, following the formats defined in IETF RFC 4975 [17]. 

According to TS 24.229, the IBCF acting as an exit or entry point in the IMS network supports these URI formats. 

These URI formats shall be supported at the II-NNI. Other URI formats may be supported over the II-NNI depending 
on the operators' policies. 

A global number as defined in IETF RFC 3966 [14] shall be used in a tel-URI or in the user portion of a SIP URI with 
the user=phone parameter when conveyed via a non-roaming interface in the Request-URI and in the P-Asserted- 
Identity header, except when agreement exists between the operators to also allow other kinds of numbers. 

NOTE 1 : In a SIP URI the user portion of the Request-URI represents a telephone number only if the SIP URI 
includes user=phone parameter. 

NOTE 2: Agreements can exist between operators to allow non-global numbers (e.g. national service numbers, 

business trunking numbers, or private numbers) at a non-roaming II-NNI. A SIP URI with such a number, 
user=phone, and a phone context agreed between the operators can then be used. 

NOTE 3: 3GPP TS 24.229 [5] allows to restrict the number within a SIP Request-URI with user=phone at a non- 
roaming II-NNI to be a global number (i.e. E.164 in international format) via an appropriate Application 
Server. Suitable configuration by the operator is needed to achieve the desired modification of the format. 

NOTE 4: The allowed phone number formats in the P-Asserted-Identity header field of a served user are configured 
by the operator. According to 3GPP TS 23.003 [33], international E.164 format is used within a P- 
Asserted-Identity header field. 

NOTE 5: The global number format usage within a SIP Request-URI with user=phone at a non-roaming II-NNI 
allows the terminating network to find the called subscriber, via HSS interrogation, without any further 
number translation and thus improves the success of the interconnection between IMS Operators. 



IP Version 



The network elements interconnected by means of the II-NNI may support IPv4 only, IPv6 only or both. 
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The support of one or both of the IP versions is an operator option and should be based on bilateral agreement. 

In case IPv4 and IPv6 networks are interconnected, the involved IBCFs and TrGWs shall apply the IP version 
interworking procedures as indicated in 3GPP TS 29.162 [8]. 



10 Security 



The supported security mechanisms for IP signalling transport over II-NNI interfaces are described in 3GPP TS 33.210 
[10]. 



1 1 Charging 



The accounting information to be supported over the Ici is described in 3GPP TS 32.260 [29]. It shall be configurable 
by the operator to use or not the accounting mechanisms provided by the IBCF. 



12 Supplementary services associated with the IIVIS 
multimedia telephony communication service 

12.1 General 

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), 
the associated supplementary services of the multimedia telephony communication service may be supported on the II- 
NNI between the two IMS networks. 

The MMTel communication service is identified by means of the media feature tag H-g.3gpp.icsi-ref set to "urn:urn- 
7:3gpp-service.ims.icsi.mmtel". The media feature tag can appear in the Contact header field, the Accept-Contact 
header field and the P-Asserted-Service header field. 

The support of each associated supplementary service is based on agreement between operators. 

If a supplementary service is supported, the related procedures from the 3GPP TS 22. 173 [30], the protocol details from 
the 3GPP TS 24.173 [31] and specifications referenced in the later specification shall be applied with the requirements 
in the relevant subclausefollowing restrictions due to the crossing of the II- NNI. 

12.2 Malicious Communication IDentification (MCID) 

Service specific requirements in accordance with 3GPP TS 24.616 [33] shall be supported over the II-NNI. 

The INFO request and the 200 (OK) response to the INFO request containing the application/vnd.etsi.mcid-nxml body 
defined in 3GPP TS 24.616 [33] may be supported at the II-NNI. 

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the 
mcid-Hxml body, as specified in the 3GPP TS 24.616 [32], if an agreement to use the MCID supplementary service 
according to the 3GPP TS 24.616 [32] exists with the network originating the dialog and if the INVITE request received 
by the terminating network does not contain the information of the originating party. 

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an 

agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [32] and 3GPP 
TS 24.229 [5]. 

The originating network and the terminating network shall have a bilateral agreement to support transportation of the 
minimum information specified in subclause 4.5.2.5.0 of the 3GPP TS 24.616 [33] between the networks. 
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Annex A (informative): 
Summary of SIP headers fields 

A summary of the SIP headers to be used in case of interconnection by using II-NNI is proposed in table A. 1 . 

The starting point is the sending behaviour described for proxy and UA roles in annex A of 3GPP TS 24.229 [5]. In 
case of misalignment between table A.l and the behaviour described in 3GPP TS 24.229 [5], the behaviour in 3GPP TS 
24.229 [5] has the precedence. In case a header is not described in table A.l and it is described in [5], description in 
3GPP TS 24.229 [5] is applicable over II-NNI. 

The notation of the codes used for the SIP headers listed in table A. 1 has a different meaning to the one proposed for the 
SIP messages. The definition of these terms is provided in table A.2. 
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Table A.1 : Supported headers 



Item 


Header 


Ret. 


ll-NNI 


1 


Accept 


[51 


m 


2 


Accept-Contact 


[51 


m 


3 


Accept-Encoding 


[51 


m 


4 


Accept-Language 


[51 


m 


5 


Alert- Info 


[51 





6 


Allow 


[51 


m 


7 


Allow-Events 


[51 


m 


8 


Authentication-Info 


[5] 


m on roaming ll-NNI, else n/a 


9 


Authorization 


[51 


m on roaming ll-NNI, else n/a 


9a 


Answer-IVIode 


[51 





10 


Call-ID 


[51 


m 


11 


Call-Info 


[51 


m 


12 


Contact 


[51 


m 


13 


Content-Disposition 


[51 


m 


14 


Content-Encoding 


[5] 


m 


15 


Content-Language 


[51 


m 


16 


Content-Length 


[51 


m 


17 


Content-Type 


[51 


m 


18 


Cseq 


[51 


m 


19 


Date 


[51 


m 


20 


Error-Info 


[51 





21 


Expires 


[51 


m 


22 


Event 


[51 


m 


23 


From 


[51 


m 


24 


Geolocation 


[51 


m 


25 


History-Info 


sub-clause 
6.1.1.3.1 


m in case of a trust relationship between the interconnected 
networks, else n/a 


25a 


Info-Package 


[5] 





26 


In-Reply-To 


[51 





27 


Join 


[51 





27a 


IVIax-Breadth 


[51 


n/a 


28 


Max-Forwards 


[51 


m 


29 


IVIin-Expires 


[51 


m 


30 


MIME-Version 


[51 


m 


31 


Min-SE 


[51 


m 


32 


Organization 


[51 


m 


33 


P-Access-Network- 1 nf o 


sub-clause 
6.1.1.3.1 


m in case of a trust relationship between the interconnected 
networks, else n/a 


33a 


P-Answer-state 


[5] 





34 


P-Asserted-ldentity 


sub-clause 
6.1.1.3.1 


m in case of a trust relationship between the interconnected 
networks, else n/a 


35 


P-Asserted-Service 


sub-clause 
6.1.1.3.1 


m in case of a trust relationship between the interconnected 
networks, else n/a 


35a 


P-Associated-URI 


[51 


m on roaming ll-NNI, else n/a 


36 


P-Called-Party-ID 


[5] 


m on roaming ll-NNI, else n/a 


37 


P-Charging-Function- 
Addresses 


[51 


n/a 


38 


P-Charging-Vector 


sub-clause 
6.1.1.3.1 


m 


38a 


P-Debug-ld 


[51 





39 


P-Early-IVIedia 


[51 


m 


40 


P-IVIedia-Authorization 


[51 


n/a 


41 


P-Preferred-ldentity 


[51 


n/a 


42 


P-Preferred-Service 


[5] 


m on roaming ll-NNI, else n/a 


43 


P-Private-Network-lndication 


sub-clause 
6.1.1.3.1 


m on roaming ll-NNI, else o 


44 


P-Profile-Key 


sub-clause 
6.1.1.3.1 


on roaming ll-NNI, else n/a 


45 


P-Served-User 


sub-clause 
6.1.1.3.1 


m on roaming ll-NNI, else n/a 


46 


P-User-Database 


[51 


n/a 


47 


P-VJsited-Network-ID 


[5] 


m on roaming ll-NNI, else n/a 
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Item 


Header 


Ref. 


ll-NNI 


47a 


Path 


[5] 


m on roaming ll-NNI, else n/a 


48 


Priority 


[5] 





48a 


Priv-Answer-Mode 


[51 





49 


Privacy 


[51 


m 


50 


Proxy-Authenticate 


[5] 


m on roaming ll-NNI, else n/a 


51 


Proxy-Authorization 


[5] 


m on roaming ll-NNI, else n/a 


52 


Proxy- Require 


[51 


m 


53 


Reason 


[51 





54 


Record-Route 


[51 


m 


54a 


Recv-lnfo 


[51 





55 


Referred-By 


[51 


m 


55a 


Refer-Sub 


[5] 


m in the case the REFER request is supported, else n/a 


55b 


Refer-To 


[51 


m in the case the REFER request is supported, else n/a 


56 


Reject-Contact 


[51 


m 


57 


Replaces 


[51 





58 


Reply-To 


[51 





59 


Request-Disposition 


[51 


m 


60 


Require 


[51 


m 


61 


Resource-Priority 


sub-clause 
6.1.1.3.1 





61a 


Retry-After 


[51 





62 


Route 


[51 


m 


63 


Security-Client 


[51 


n/a 


64 


Security-Verify 


[51 


n/a 


65 


Server 


[51 





65a 


Service-Route 


[51 


m on roaming ll-NNI, else n/a 


66 


Session-Expires 


[51 


m 


67 


Subject 


[51 





68 


Supported 


[51 


m 


69 


Timestamp 


[51 


m 


70 


To 


[51 


m 


71 


Trigger-Consent 


[51 


m 


72 


User-Agent 


[51 


m 


73 


User-to-User 


[51 





74 


Via 


[51 


m 


75 


Warning 


[51 





76 


www-Authenticate 


[51 


m on roaming ll-NNI, else n/a 



Table A.2: Key to notation codes for SIP headers 



Notation 
code 


Meaning 


m 


The SIP header is applicable at ll-NNI. 

Supporting sending a SIP header at the ll-NNI means that this header 

is passed through the IBCF. It does not imply that network elements 

inside the networks support this header, where 3GPP TS 24.229 [5] is 

applied. If specified in 3GPP TS 24.229, an IBCF modifies the SIP 

header. 





The applicability of SIP header at ll-NNI depends on bilateral 
agreement between the operators. 


n/a 


It is impossible to use the SIP header at the ll-NNI. This header could 
be discarded by the IBCF. 
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